前言

這篇文章比較是條列式的列出講者在slack快速發展中學到的幾件事情，適合給快速成長的公司中的leader（例如我蝦XD）來參考，特別是你team一年內會翻倍成長的那些leader們。

演講摘要

這篇演講主要是分享幾個在Slack快速發展的過程中，講者學到的各種事情，也可以給大家參考要怎麼在快速發展中存活下去。

時代背景是這樣，Slack從花了5年時間從不到1M的Daily Active Users（DAU）成長到10 million DAUs。中間除了要支持用戶增加之外，也必須要支持企業級用戶，還有第三方的application，更重要的是hire了爆多人，幾乎每週都有新人onboard。各種壓力排山倒海而來，而且沒有回頭路。

講者列了十點這幾年來的學習歷程：

1. 寫作是重要的資產。
   這裡講的寫作比較是給自己的記錄，因為寫作能夠幫助整理你的思緒，讓你言之有物，所以在聽演講的時候記下東西，或者在跟別人討論之前先列下自己要敘述的點是非常有用的。
2. 故事的力量不可小覷。
   對於leader來說，大部分的時候是與人溝通，而說故事其實是溝通一個很重要的方法。有點像是你在賣東西（sales），只是你在賣的是一個概念或一個信仰。你把你想傳達的內容包裝成故事，讓別人願意去買你的商品跟聽進你的說的話。
3. 準備好溝通的框架與模版。
   意思就是把工程師思維用在溝通上。在快速發展的公司裡，你沒有太多時間對每件事情都重新思考要怎麼有效溝通，所以準備好模版幫助你思考與準備可以節省你很多的時間。就好像寫feature時我們會把常用的function寫成library以減少重複的操作或重複思考的時間。
4. 了解你的聽眾是誰。
   這個有點溝通學的老生常談，總之溝通最困難的一部分就是你要理解你的聽眾，知道他們在乎的是什麼，才能有效率的溝通。
5. 太多會議通常代表沒共識（misalignment）。
   為了協調各式各樣team與team之間的事，我們常常會有太多會議。這通常代表大家沒有align好共同目標是什麼所以會必須不斷的開會討論。所以在發會議邀請前，可以先想我們真的需要這個meeting嗎？如果需要的話那是不是代表我們的目標是沒align的好的？有沒有辦法先align來減少這個會議。
6. 針對於你常做的事建立流程或組織架構。
   這個應該蠻好理解，就好像團隊小的時候你可以手動的規劃與委派每個人的任務，但當你人數超過七八人的時候，你必須要想個好的系統化的方式去做這些事。這裡講到一個很重要的點，你在做一些重複性的事情時，一方面你要想怎麼把事情做好，另一方面你要想怎麼系統化把你的方法論，以建立一套流程以支持未來的擴張。
7. 思考「誰是下決定的人」。
   你可能會遇到很多狀況是你不知道誰可以做決策。有一個詞叫決策地獄（decision purgatory），意思就是當沒有人知道誰可以做某個重大決定時（例如我們要用thrift或是protobuf），我們就會花時間開了一堆會，然後沒有任何產出跟結論。下面的人覺得上面的人應該做決策，但是上面的人卻不見得有visibility看到下面的現實。通常到最後就變成是上面的人要花很多時間跟下面的人align理解要怎麼做決定。
8. 功勞總是流向資深的人。
   因為資深的人或者是leader會有比較多的曝光，所以很多時候功勞自然而然會流向這些人身上。但如果你是個leader，你必須要讓那些真正應該有貢獻的人獲得到應有的功勞與獎勵。
9. 你帶領的組織就像一面鏡子，會映照出你自己的模樣。
   你可能會發現，很多組織的高官的個性會跟老闆很像，因為通常同質性高的人很容易被promote。所以當你在hire人的時候，你要想你要怎麼找到能與你的弱項互補的人？因為充滿多樣性的組織通常建立的產品更好。
10. 公平對待每個人，能領導大家是你的榮幸。
    講者推薦Lora Hogan的這篇文章：managing in terrible times，有空可以看看。

個人心得

其實不知道是我的語言問題還是如何，講者列出的每個point跟我的理解都有點差異XDD。但whatever，我覺得還是不少有感觸的點，下面來講講：

關於寫作

關於寫作我覺得也是身有體悟。

我覺得練習記錄討論的點是蠻重要的，我自己會在1-1 meeting或者遇到某些事件之後特別的利用STAR方法記錄一下發生的事情經過，一開始有這個想法是為了準備behavioral interview XD，但後來好像變成了個習慣。一方面是真的是可以幫你整你思緒，另一方面是整理故事對於leadership來說很重要就跟講者講的說故事那點一樣。

故事的力量

因為人是難搞的生物，不容易相信別人直接給你的結論，但是可以接受經由故事你自己得出來的結論。而我自從意識到「講故事的重要性」後就買了一堆書在看到底要怎麼說故事，但看了半天很多書都是在講故事的重要性但沒講怎麼找故事XDD，這也是為什麼我會做上面講的練習整理平常身邊發生的事件，因為最終在跟別人溝通的時候，這些之前整理的故事其實都會變成很好的素材。

另外我也發現到一件有趣的事：對於junior來說常常遇到的問題是描述事情抓不到重點，講了100%的東西只有10%是重點。而為了增加溝通效率我們開始精簡化我們講的內容，變成一層一層的抽象，然後我們終於可以講的很精簡了！但這卻變成導致大家反而聽不懂我們講什麼了囧>。所以到了最後我們要溝通，還是必須要用說故事的方式去跟別人溝通。因為人喜歡聽故事，但不喜歡聽抓不到或沒有重點的故事。

Communication engineering

我覺得這個idea超有趣。工程學其實就是把現實的生活方式抽象成系統或流程以達到簡化與增加效率的目的（例如蝦皮就是把現實的買賣市場轉化成一套線上系統，電子錢包也是為了減少紙鈔交易帶來的麻煩）。而身為工程師，我們其實非常熟悉這套思考流程，所以會自然而然的想在生活上把所有事情「工程化」，包含這邊講到的溝通。我自己受用比較多的是在interview描述事情的STAR framework，其實就是個蠻好的溝通template。如果你有考過GRE或TOEFL，那你可能會理解口說/寫作模版的重要性，其實就是為了標準化你的思考流程與讓你可以專注在內容產生上。

之前曾經有點紅的四色溝通術，某種程度就是communication engineering的產物，因為不同的人有不同的溝通方式，所以如果你可以把你的聽眾做某種程度的分類，這樣在跟他們溝通的時候就能比較有效率一些。

會議太多

我是完全可以理解講者說大部分會議其實都是在建立共識，但我自己是不覺得有共識就能解決問題就是了XD。

決策地獄

這個真的是認同到五體投地XD。一段痛苦的經驗是之前有一陣子我們在反思+重想產品架構的時候，跟老闆們開了很多會，七嘴八舌各種討論，但每次討論了一個小時好像都蠻難得得出什麼結論。一方面老闆對於現階段的細節並不太熟悉只知道大方向，但要做決定其實又需要這些細節，而要把所有細節交代清楚又是件很花時間的工作，所以就如此往赴，前前後後討論半天都不知道在講什麼。後來我自己的策略是，我自己先訂好想好提proposal，在會議上只需要說服老闆們我的決定就好。而這樣的做的成果看起來的確是有效率些。

我記得很久以前看過有人說，其實老闆都希望下面的人在找你討論的時候都已經腦中有個解決方案，而不是單純尋求老闆幫助。我是可以完全體會這種感受，所以當我在跟老闆討論東西時通常會先想一兩個可行的解法來討論，這樣一方面溝通起來可以有效率非常多（你甚至可以先準備一些資料或圖表表達你的想法），另一方面是我相信老闆也沒什麼時間想這些XD"，所以先想好可能也是能幫到他們忙哈哈。

組織即自我的投射

這個想法我第一次被戳到，我深深覺得自己就是這樣子的人RRR。現在回想起來，我完全可以理解會想promote跟你類似的人的想法，我的確在看人的時候從來沒有想過用diversity的角度去看事情，某種程度上也是對自己的自負覺得類似自己這樣子的人比較好吧。除了在對待團隊會這樣，在面試別人時可能也會這樣，仔細想想好像也是蠻危險的。這點真的是銘記在心，未來要小心注意這點。

不過關於「充滿多樣性的組織通常建立的產品更好」這點我是有疑問，我可以理解多樣性帶來的好處，但也有很大部分是多樣性帶來的效率的犧牲，不確定有沒有辦法在維持多樣性的同時還能夠保有效率，無論是對產品或帶團隊都是。

講者Julia Grace之前我就聽過她在QCon的演講：Scaling infrastructure Engineering at Slack，講述更多Slack的快速發展過程，內容超有趣的因為跟鄙司S社有很多相似的地方，所以各種感同身受。她有著兩年內從10人團隊變成100人團隊的經驗，突然覺得跟我們老闆的經驗或許非常的類似。